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Abstract.  Suppose  we  translate  two  different  source  languages,  L\  and  L2,  into 
the  same  intermediate  language;  can  they  safely  interoperate  in  the  same  address 
space  and  under  the  same  runtime  system?  If  Li  supports  first-class  continua¬ 
tions  (call/cc)  and  L 2  does  not,  can  L2  programs  call  arbitrary  L\  functions? 
Would  the  fact  of  possibly  calling  L 1  impose  restrictions  on  the  implementation 
strategy  of  L2?  Can  we  compile  L 1  functions  that  do  not  invoke  call/cc  using 
more  efficient  techniques  borrowed  from  the  L2  implementation?  Our  view  is 
that  the  implementation  of  a  common  intermediate  language  ought  to  support  the 
so-called  pay-as-you-go  efficiency:  first-order  monomorphic  functions  should  be 
compiled  as  efficiently  as  in  C  and  assembly  languages,  even  though  they  may 
be  passed  to  arbitrary  polymorphic  functions  that  support  advanced  control  prim¬ 
itives  (e.g.  call/cc).  In  this  paper,  we  present  a  typed  intermediate  language  with 
effect  and  resource  annotations,  ensuring  the  safety  of  inter-language  calls  while 
allowing  the  compiler  to  choose  continuation  allocation  strategies. 


1  Introduction 

Safe  interoperability  requires  resolving  a  host  of  issues  including  mixed  data  represen¬ 
tations,  multiple  function  calling  conventions,  and  different  implementation  protocols. 
Existing  approaches  to  language  interoperability  either  separate  code  written  in  differ¬ 
ent  languages  into  different  address  spaces  or  have  the  unsafe,  ad  hoc  and  insecure 
foreign  function  call  interface. 

We  position  our  further  discussion  of  language  interoperability  in  the  context  of 
a  system  hosting  multiple  languages,  each  safe  in  isolation.  The  supported  languages 
may  range  from  first-order  monomorphic  (e.g.  a  safe  subset  of  C,  or  safe-C  for  short)  to 
higher-order  languages  with  advanced  control,  e.g.  ML  with  first-class  continuations. 
We  assume  that  all  languages  have  type  systems  which  ensure  runtime  safety  of  ac¬ 
cepted  programs.  In  other  words,  in  this  paper  we  do  not  attempt  to  solve  the  problem 
of  cooperating  safely  with  programs  written  in  unsafe  languages,  which  in  general  can 
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only  be  achieved  at  the  expense  of  “sandboxing”  the  unsafe  calls  or  complex  and  in¬ 
complete  analyses  of  the  unsafe  code. 

We  believe  that  interoperability  requires  a  serious  and  more  formal  treatment.  As 
a  first  step,  this  paper  describes  a  novel  type-based  technique  to  support  principled 
language  interoperation  among  languages  with  different  protocols  for  allocation  of  ac¬ 
tivation  records.  Our  framework  allows  programs  written  in  multiple  languages  with 
overlapping  features  to  interact  with  each  other  safely  and  reliably,  yet  without  restrict¬ 
ing  the  expressiveness  of  each  language. 

An  interoperability  scheme  for  activation  record  allocation  should  be 

-  safe:  it  should  not  be  possible  to  violate  the  runtime  safety  of  a  language  by  calling 
a  foreign  function; 

-  expressive:  the  scheme  should  allow  inter-language  function  calls; 

-  efficient:  a  language  implementation  should  not  be  forced  to  use  suboptimal  meth¬ 
ods  for  its  own  features  in  order  to  provide  support  for  other  languages’  features. 
For  instance  a  language  that  does  not  use  call/cc  should  not  have  to  be  implemented 
using  heap-based  allocation  of  activation  records. 

Our  solution  is  to  ensure  safety  by  using  a  common  typed  intermediate  language  [21] 
into  which  all  of  the  source  languages  are  translated.  To  maintain  safety  in  an  expres¬ 
sive  interoperability  scheme  the  type  system  is  extended  with  annotations  of  the  effects 
of  the  evaluation  of  a  term,  e.g.  an  invocation  of  call/cc,  and  polymorphic  types  with 
effect  variables,  allowing  a  higher-order  function  to  be  invoked  with  arguments  com¬ 
ing  from  languages  with  different  sets  of  effects.  The  central  novelty  of  our  approach 
is  the  introduction  of  annotations  of  the  resources  necessary  for  the  realization  of  the 
effects  of  an  evaluation;  for  instance  a  continuation  heap  may  be  required  when  invok¬ 
ing  call/cc.  Thus  our  type  system  can  be  used  to  support  implementation  efficiency  by 
keeping  track  of  the  available  language-dependent  resources,  and  safety  by  allowing 
semantically  correct  inter-language  function  calls  but  banning  semantically  incorrect 
ones.  In  addition  to  providing  safety,  making  resource  handling  explicit  also  opens  new 
opportunities  for  code  optimization  beyond  what  a  foreign  function  call  mechanism  can 
offer. 

A  common  intermediate  language  like  FLINT  [20,  21]  will  likely  support  a  very 
rich  set  of  features  to  accommodate  multiple  source  languages.  Some  of  these  features 
may  impose  implementation  restrictions;  for  example,  a  practical  implementation  of 
first-class  continuations  (as  in  SML/NJ  or  Scheme)  often  requires  the  use  of  advanced 
stack  representations  [8]  or  heap-based  activation  records  [22],  However  in  some  cases 
stack-based  allocation  may  be  more  efficient,  and  ideally  we  would  like  to  have  a  com¬ 
piler  that  can  take  advantage  of  it  as  long  as  this  does  not  interfere  with  the  semantic 
correctness  of  first-class  continuations.  Similarly,  when  compiling  a  simple  safe-C-like 
language  with  no  advanced  control  primitives  (e.g.,  call/cc)  into  FLINT,  we  may  pre¬ 
fer  to  compile  it  to  code  that  uses  the  simple  sequential  stack  of  standard  C;  programs 
written  in  ML  or  Scheme  using  these  safe-C  functions  must  then  follow  the  same  al¬ 
location  strategy  when  invoking  them.  This  corresponds  to  the  typical  case  of  writing 
low-level  systems  modules  in  C  and  providing  for  their  use  in  other  languages,  therefore 
we  assume  this  model  in  the  sequel,  but  the  dual  problem  of  compiling  safe-C  functions 


calling  arbitrary  ML  functions  by  selectively  imposing  heap  allocation  on  safe-C  is 
similarly  represented  and  solved  within  our  system. 

Thus  our  goal  is  efficient  and  expressive  interoperability  between  code  fragments 
written  in  languages  using  possibly  different  allocation  disciplines  for  activation  records, 
for  instance,  ML  with  heap  allocation  and  safe-C  with  stack  allocation.  The  following 
properties  of  the  interoperability  framework  are  essential  for  achieving  this  goal: 

-  ML  and  safe-C  code  should  interoperate  safely  with  each  other  within  the  same 
address  space. 

-  All  invocations  of  safe-C  functions  in  ML  functions  should  be  allowed  (provided 
they  are  otherwise  type-correct). 

-  Only  the  invocations  of  ML  functions  that  do  not  capture  continuations  should  be 
allowed  in  safe-C  functions. 

-  Any  activation  record  that  can  potentially  be  captured  as  part  of  a  first-class  contin¬ 
uation  should  always  be  allocated  on  the  heap  (or  using  some  fancy  stack-chunk- 
based  representations  [8]). 

-  It  should  be  possible  to  use  stack  allocation  for  activation  records  of  ML  functions 
when  they  are  guaranteed  not  to  be  captured  with  a  first-class  continuation. 

-  The  selection  of  allocation  strategy  should  be  decoupled  from  the  actual  function 
call. 

The  last  property  gives  the  compiler  the  freedom  to  switch  allocation  strategies  more 
efficiently,  instead  of  following  a  fixed  foreign  function  interface  mechanism.  For  exam¬ 
ple,  an  implementation  of  ML  may  use  heap  allocation  of  activation  records  by  default 
to  provide  support  for  continuation  capture.  However,  in  cases  when  the  compiler  can 
prove  that  a  function’s  activation  record  is  not  going  to  be  accessible  from  any  captured 
continuation,  its  allocation  discipline  is  ambiguous;  stack  allocation  may  be  preferred 
if  the  function  invokes,  or  is  invoked  by,  safe-C  functions  which  use  stack  allocation. 
This  specialization  of  code  to  a  different  allocation  strategy  effectively  creates  regions 
of  ML  code  compiled  in  “safe-C  mode”  with  the  aim  of  avoiding  the  switch  between 
heap  and  stack  allocation  on  every  cross-language  call.  In  general,  the  separation  of  the 
selection  of  allocation  strategy  from  the  call  allows  its  treatment  as  a  commodity  prim¬ 
itive  operation  and  subjects  it  to  other  code-motion  optimizations,  e.g.  hoisting  it  out  of 
loops. 

The  proposed  method  can  be  applied  to  achieving  more  efficient  interoperability 
with  existing  foreign  code  as  well,  although  obviously  in  this  case  the  usual  friction 
between  safety  and  efficiency  can  only  be  eased  but  not  removed.  In  particular  the 
possibility  to  select  the  allocation  strategy  switch  point  remains,  thus  higher  efficiency 
can  still  be  achieved  while  satisfying  a  given  safety  policy  by  specializing  safe  code  to 
“unsafe  mode”  (e.g.  for  running  with  stack  allocation  within  a  sand-box). 

2  A  Resourceful  Intermediate  Language 

To  satisfy  the  requirements  for  efficient  interoperability,  outlined  in  the  previous  sec¬ 
tion,  we  define  an  A-normal-form-based  typed  intermediate  language  RL  (Figure  1) 
with  types  having  effect  and  resource  annotations.  Intuitively,  an  effect  annotation  such 


as  CC  indicates  that  a  computation  may  capture  a  continuation  by  performing  call/cc; 
a  resource  annotation  such  as  H  (continuation  heap)  or  S  (continuation  stack)  means 
that  the  corresponding  runtime  resource  must  be  available  to  the  computation.1  Non¬ 
trivial  effects  can  be  primitive,  effect  variables,  or  unions  of  effects;  commutativity  and 
associativity  of  the  union  with  0  as  a  unit  are  consistent  with  the  typing  rules  and  we 
assume  them  for  brevity  of  notation.  Each  effect  can  only  occur  when  the  proper  re¬ 
sources  are  available,  e.g.  CC  would  require  the  use  of  heap-based  activation  record 
allocation.  Both  the  effect  and  resource  usage  annotations  are  inferred  during  the  trans¬ 
lation  from  the  source  language  to  the  intermediate  language,  and  can  be  used  to  assist 
code  generation  and  to  check  the  validity  of  cross-language  function  calls. 
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Fig.  1.  Syntax  of 

a  resource-; 

aware  intermediate  language  RL 

The  resources  required  and  effects  produced  by  a  function  are  made  explicit  in  its 
type.  A  continuation  can  potentially  produce  all  effects  possible  with  the  set  of  re¬ 
sources  available  at  the  point  of  its  capture;  for  that  reason  continuation  types  only  have 
a  resource  annotation. 


1  In  this  paper,  we  focus  on  application  of  this  system  to  interoperability  issues  related  to  contin¬ 
uation  allocation,  but  more  diverse  sets  of  resources  will  be  necessary  in  a  realistic  language. 


Function  abstractions  are  annotated  with  the  resources  they  may  require  and  will 
maintain.  In  a  higher-order  language  the  effect  of  the  evaluation  of  a  function  applica¬ 
tion  may  depend  on  the  effects  of  its  functional  arguments;  this  dependence  is  expressed 
by  means  of  effect  polymorphism.  Polymorphic  abstractions  introduce  variables  rang¬ 
ing  over  the  set  of  possible  effects  of  the  term.  Since  the  possible  effects  are  determined 
by  the  available  resources,  we  have  bounded  effect  polymorphism ;  the  relation  p  <  r 
(defined  in  the  context  of  an  effect  environment  in  Figure  3)  reflects  the  dependence 
between  effects  and  resources,  e.g.  that  callcc  can  only  be  performed  if  continuations 
are  heap-allocated.  The  effect  application  x\p\  instantiates  the  body  of  the  polymorphic 
abstraction  to  which  x  is  bound.  The  language  construct  user  (e)  serves  to  mark  the 
point  where  a  change  in  the  allocation  strategy  for  activation  records  is  required.  In¬ 
stead  of  having  effect  subsumption  the  language  is  equipped  with  a  construct  (e)f,.  for 
explicitly  increasing  the  set  of  effects  of  e  to  include  p. 

Example  1.  The  use  of  resource  annotations  to  select  allocation  strategies  is  shown  in 
the  RL  code  below  which  includes  extra  type  annotations  for  clarity. 

letH 

applyToInt  =  (At<  H.  AH  f :  Int  4  Int.  @  f  42)H 
:  Vt<  H.  (Int  4  Int)  A  Int 

~  t  t 

addl.CC  ={AHx:lnt. 

letH  c  =  (AH  k:  Int  Hcont. 

letH  z  =  @  succ  x  in  throw[lnt]  k  z)H 

in  callcc  c)H 

:  Int  4  Int 

cc 

addl.Pure  =  (As  x:  Int.  @  succ  x)H 

:  Int  4  Int 

0 

addl.Wrapped  =  (AH  x:  Int.  uses  (@  addl.Pure  x))H 

:  Int  4  Int 

0 

in  a  (applyTolnt[CC])  addl.CC; 
a  (applyTolnt[0])  addl.Wrapped 

The  function  applyToInt  is  polymorphic  in  the  effect  of  its  parameter,  but  the  param¬ 
eter’s  resource  requirements  are  fixed  -  it  must  use  heap  allocation.  We  consider  two 
applications  of  applyToInt.  The  argument  in  the  first,  addl_CC,  is  a  function  invoking 
callcc,  which  consequently  uses  heap  allocation;  on  the  other  hand  the  argument  in  the 
second  application,  addl_Pure,  is  pure  and  uses  stack  allocation.  It  is  therefore  incor¬ 
rect  to  apply  applyToInt  to  addl_Pure.  We  use  a  wrapper  to  coerce  it  to  the  proper  type: 


we  apply  applyToInt  to  addl_Wrapped  whose  activation  record  is  heap-allocated,  and 
whose  function  is  to  switch  to  stack  allocation  (via  uses)  before  calling  addl_Pure. 
Heap  allocation  is  resumed  upon  return  from  addl_Pure. 


3  Two  Source  Languages 

To  further  illustrate  the  advantages  of  this  system  we  consider  the  problem  of  trans¬ 
lating  into  RL  two  source  languages  (Figure  2):  a  language  HL  with  control  operators 
(callcc  and  throw),  implemented  using  heap-based  allocation  of  activation  records,  and 
a  language  SL  which  always  uses  stack  allocation.  HL  also  allows  declaring  at  the  top 
of  a  program  the  identifiers  of  entities  imported  from  SL  code.  The  type  systems  of 
these  languages  are  assumed  monomorphic  for  simplicity,  since  polymorphism  in  types 
is  largely  orthogonal  to  the  effect  polymorphism  of  RL. 
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|  callcc  eHL  |  throw[rHL 

&HL  &HL 

HL Programs 

Phl 

:=  eHL 

|  external  (SL)  x  : 

tSl  in  pHL 

Fig.  2.  Syntax  of  the  source  languages  SL  and  HL 


The  resource  annotations  in  RL  provide  information  about  handling  of  the  stack  and 
heap  resources,  necessary  in  the  following  situations: 

-  when  calling  from  HL  a  function  written  in  SL.  which  may  require  switching  from 
heap  allocation  of  activation  records  to  allocation  on  the  stack  used  by  SL\  the  heap 
resource  must  be  preserved  for  use  upon  return  from  SL  code. 

-  when  calling  an  HL  function  from  SL  code,  which  is  only  semantically  sound  when 
the  evaluation  of  the  function  does  not  capture  a  continuation,  since  part  of  the 
continuation  data  is  stack-allocated;  the  type  system  maintains  information  about 
the  possible  effects  of  the  evaluation,  in  this  case  whether  callcc  might  be  invoked. 

-  when  selecting  an  allocation  strategy  for  HL  functions  called  (directly  or  indirectly) 
from  within  SL  code;  either  their  activation  records  must  be  allocated  on  the  SL 
stack,  or  the  latter  must  be  preserved  and  restored  upon  return  to  SL. 

-  when  selecting  an  allocation  strategy  for  HL  code  invoking  SL  functions  but  not 
callcc,  in  order  to  optimize  resource  handling. 


Example  2.  Consider  a  program  consisting  of  a  main  fragment  in  HL  invoking  the 
external  SL  function  applyToInt  with  the  HL  function  addl  as  an  argument;  the  call 
is  meaningful  because  addl  does  not  invoke  callcc.  Only  the  SL  type  of  the  external 
function  is  given  to  the  HL  program  which  is  separately  compiled  without  access  to  the 
detailed  effect  annotations  inferred  from  the  code  of  the  SL  fragment. 


SL  fragment  applyToInt: 

Af  :  Int  — »  Int.  succ  (f  42) 


The  result  of  its  separate  compilation  into  RL,  which  uses  stack  allocation  (for  details 
of  the  translation  we  refer  the  reader  to  Section  5)  is 


applyToInt  =  At<  S.  As  f :  Int  -A  Int.  Iets  x  =  @  f  42  in  a  succ  x 
:  Vt<S.  (Int  A  Int)  A  Int 

“  t  t 


HL  fragment  main: 

external(SL)  applyToInt :  (Int  -»  Int)  -t  Int 
in  let  addl  =  Ax  :  Int.  succ  x 
in  applyToInt  addl 

The  result  of  its  separate  compilation  into  RL  is 

main  =  AH  applyTolnt:Vt<S.  (Int  A  Int)  A  Int. 

letH 

applyTolnt_H  =  (At<S. 

AH  f:  Int  A  Int. 

t 

letH  f_S  =  (As  x:  Int.  useH  (@  f  x))H 
in  uses  (@  (applyTolnt[t])  f-S))H 
:  Vt<S.  (Int  A  Int)  A  Int 

~  t  0 

addl  =  (Ah  x:  Int.  @  succ  x)H 

:  Int  A  Int 

0 

in  ®  applyTolnt_H[0]  addl 

:  (  Vt  <  S.  (Int  A  Int)  A  Int  ]  A  Int 
V  ~  t  0  )  0 

The  translation  infers  polymorphic  effect  types  using  a  simplified  version2  of  standard 
effect  inference  [23].  The  resource  annotations  are  fixed  by  the  source  language;  the 
type  of  an  external  SL  function  in  an  HL  program  is  annotated  with  the  SL  resources. 
In  the  code  produced  after  translation  the  external  functions  are  coerced  to  match  the 
resources  of  HL  using  automatically  generated  wrappers.  In  the  above  code,  the  param¬ 
eter  f  of  applyTolnt_H  is  wrapped  to  f_S  before  passing  it  to  applyToInt;  the  function 
of  the  wrapper  is  to  switch  from  the  stack  allocation  discipline  used  by  SL  to  heap  allo¬ 
cation  before  invoking  the  code  for  f,  and  resume  stack  allocation  upon  return.  Dually, 
the  call  to  applyToInt  itself  is  wrapped  to  enable  stack  allocation  inside  HL  code. 

2  As  presented  here  our  system  does  not  keep  track  of  regions  associated  with  effects. 


Since  the  full  RL  type  of  the  SL  fragment  is  not  available  to  it,  the  effect  inference 
must  conseratively  approximate  the  effects  of  the  SL  functions.  It  treats  the  external 
applyToInt  in  the  HL  fragment  as  an  effect-polymorphic  parameter  in  order  to  allow 
its  invocations  with  arguments  with  different  effects.  The  price  we  pay  for  inference 
with  this  polymorphism  in  the  case  of  separate  compilation  is  that  we  assume  that  the 
effects  of  these  invocations  are  the  maximal  allowed  with  the  resources  shared  between 
the  languages  (in  Example  2  we  lose  no  precision  since  SL  has  no  effects,  but  the  ap¬ 
proximation  is  reflected  in  the  effect  annotation  0  of  the  type  of  the  parameter  of  main). 
The  following  code,  constructed  mechanically  given  the  inferred  and  expected  types 
of  applyToInt,  coerces  the  actual  type  of  applyToInt  to  the  approximation  used  in  the 
typing  of  main  and  performs  the  top-level  application,  thus  linking  the  modules. 

letH 

applyTolnt_Glue  =  (At<S.  As  f :  Int  A  Int.  (©  applyTolnt[t]  f)a)H 
:  Vt<S.  (Int  A  Int)  A  Int 

“  t  0 

in  a  main  applyTolnt_Glue 

More  precise  inference  of  the  resulting  effects  is  possible  when  the  external  function 
is  a  pre-compiled  library  routine  whose  RL  type  (with  its  precise  effect  annotations) 
is  available  when  compiling  main.  In  those  cases  we  can  take  advantage  of  the  let- 
polymorphism  in  inferring  a  type  of  main  (in  a  setting  similar  to  that  of  Example  1). 
However  even  the  approximated  effects  obtained  during  separate  compilation  carry  in¬ 
formation  that  can  be  exploited  for  the  optimization  of  inter-language  calls,  observing 
that  the  range  of  effects  of  a  function  is  limited  by  the  resources  of  its  source  language. 
In  Example  2,  after  inlining  and  applying  results  of  Section  4.4  (Theorem  2),  the  code 
for  main  can  be  optimized  to  eliminate  the  unnecessary  switch  to  heap  allocation  in  the 
instance  of  f_S.  This  yields 

main  =  (AH  applyTolnt:Vt<  S.  (Int  A  Int)  A  Int. 

~  t  0 

letH 

addl  =  (Ah  x:  Int.  ©  succ  x)H  (*  now  dead  code  *) 
addl_S  =  (As  x:  Int.  @  succ  x)H 
in  uses  (0  (applyTolnt[0])  addl_S))H 

Thus  the  HL  function  addl  has  been  effectively  specialized  for  the  stack  allocation 
strategy  used  by  SL. 

Example  3.  Another  optimization  is  merging  of  regions  with  the  same  resource  require¬ 
ments,  illustrated  on  the  following  HL  code  fragment. 

external(SL)  intFn  :  Int  — >  Int  in  intFn  (intFn  42) 

which  is  naively  translated  to  the  RL  function  (shown  after  inlining  of  the  parameter 
wrapper) 


At<  S.  AH  intFn :  Int  A  Int. 

t 

letH  x  =  (uses  (®  intFn  42)}H 
in  uses  (a  intFn  x) 

After  combining  the  two  uses  (•)  constructs  the  equivalent  RL  term  is 

At<S.  AH  intFn:  Int  A  Int. 

t 

uses  ( lets  x  =  (a  intFn  42}s  in  a  intFn  x) 

A  generalization  of  this  transformation  makes  possible  lifting  of  user  (•)  constructs 
out  of  a  loop  when  the  resources  r  are  sufficient  for  all  effects  of  the  loop.  Since  in 
general  a  resource  wrapper  must  restore  resources  upon  return,  a  tail  call  moved  into 
its  scope  effectively  becomes  non-tail;  thus  lifting  a  wrapper’s  scope  over  a  recursive 
tail  call  is  only  useful  when  the  wrapper  is  lifted  out  of  the  enclosing  function  as  well, 
i.e.  out  of  the  loop. 

4  Semantics  of  RL 

4.1  Static  Semantics 

Correctness  of  resource  use  is  ensured  by  the  type  system  shown  in  Figure  3,  which 
keeps  track  of  the  resources  necessary  for  the  evaluation  of  a  term  and  a  conservative 
estimate  of  the  effects  of  the  evaluation. 

An  effect  environment  A  specifies  the  resource  bounds  of  effect  variables  intro¬ 
duced  by  effect  abstractions  and  effect-polymorphic  types.  The  rules  for  effect  sequents 
reflect  the  dependence  of  effects  on  resources  (in  this  language  this  boils  down  to  the 
dependence  of  the  call/cc  effect  CC  on  the  heap  allocation  resource  FI )  and  form  the 
basis  of  effect  polymorphism.  The  function  MaxEff  yields  the  maximal  effect  possible 
with  a  given  resource;  in  this  system  we  have  MaxEff  (S)  =  0  and  MaxEff  (H)  =  CC. 
Rule  (Eff-max)  effectively  states  that  the  resource  r'  can  be  used  instead  of  resource  r 
if  r'  provides  for  all  effects  possible  under  r. 

In  the  sequents  assigning  types  to  values  and  terms  the  type  environment  r  maps 
free  variables  to  types.  Type  judgments  for  values  associate  with  a  value  v  and  a  pair  of 
environments  A  and  E  only  a  type  <r,  since  values  have  no  effects  and  therefore  their 
evaluation  requires  no  resources  of  the  kind  we  control.  The  function  6  maps  constants 
to  their  predefined  types. 

Sequents  for  terms  have  the  form  r;  A;  T  he:  —a,  where  r  represents  the  avail¬ 
able  allocation  resource,  a  is  the  type  of  e,  and  f  i  represents  the  effects  of  its  evaluation. 
Rules  (Exp-let)  and  (Exp-val)  establish  the  correspondence  between  the  resource  an¬ 
notations  in  these  constructs  and  the  currently  available  allocation  resource;  the  effect 
of  lifting  a  value  to  a  term  is  none,  while  the  effect  of  sequencing  two  computations  via 
let  is  the  union  of  their  effects.  Any  effect  allowed  with  the  current  resource  may  be 
added  to  the  effects  of  a  term  using  rule  (Exp-spurious). 

The  central  novelty  is  the  user  (•)  construct  for  resource  manipulation;  its  typing 
rule  (Exp-use)  imposes  the  crucial  restriction  that  the  effect  //  of  the  term  e  must  be 


Effect  Environment  Formation 


(Env-efF-empty) 

P  0 


(Env-eff-ext) 

P1  A 

P1  At,  t  <  r 


Type  Environment  Formation 

(Env-typ-empty)  (Env-typ-ext) 

P1  zi  A  ^  r  A  a 


A  A\-r  rx,x:a 


Effects 

(EfF-empty)  (EFF-CC) 

P1  A  K  A 

A  P  0  <  r  A  P  CC  <  H 

(EFF-var)  (EFF-combine) 

P1  A  A(t)  =  r  P  i_i'  <  r,  \x'  <  r 

Z  P  t  <  r  A  P  ju'  V  ju"  <  r 

(EFF-max) 

A  P  /I  <  r  zi  P  MaxEff  (r)  <  t-* 


4;rPc:  6»(c) 


zi;r  p 


(Val-abs) 

r;zi;rx,x:a  P  e  :  -cr' 


A;  rx  P  Ar  x :  a.  e  :  a  — >■  cr' 

(Val-poly) 

zi  P  Z1  Zij,  t  <  r-,r  P  v  :  <7 


Zi;/1  P  At<r.v  :  Vt<r.  a 

(Val-tapp) 

Z’(x)  =  Vi  <r.  a  zi  P  p  <  r 
zi;T  P  x[p]  :  [p/i]cr 


Types 

(Typ-basic)  (Typ-Fun) 

|_zi^  ZiPp<rZiPc7,  cr’ 

4  p-  A  P  a  A  a 

(Typ-cont) 

zi  P  cr  0  P  CC  <  r 

zi  P  a  rcont 

(Typ-poly) 

P  zi  At,t<r  P  a 
A  P  \/t<r.a 


Terms 

(Exp-let) 

r;  A-,  r  P  e  :  -a  r ;  zi;  rx ,  x  :  cr  P  e  :  —  a' 

_ if _ _  if 

r:  A-r  P  letr  x  =  e  in  e'  :  a' 

juVju' 

(Exp-val) 

zi;  Z1  P  v  :  cr 

Tj  zi;  r  P  (v)r  :  -a 
0 

(Exp-spurious) 

r;  zi;  r  P  e  :  -cr  zi  P  /j,'  <  r 
r'i  A;  T  P  <e)„.  :  - 7<J 

/LiV/Li 

(Exp-use) 

r  \A\F  Vs  e  \  -a  A  P  /t  <  r 


r\A-,r  P  user  (e)  :  -a 
(Exp-app) 

ziPT  r(x)=a'^a  r(x')  =  a' 


r;  Zi;  T  P  <5  x  x  :  -cr 

i> 

(Exp-callcc) 

zi  |_r  z1  Z'(x)  =  <7  rcont  A  a 

_ i* 

r;  zi;  Z1  P  callcc  x  :  - a 

/uVCC 

(Exp-throw) 

zi  K  r  zi  P  o'  r(x)  =  a  rcont  Z’(x')  =  a 
r\A-,r  P  throwfg'l  x  x'  :  ~a 

MaxEff  (r) 


Fig.  3.  The  A’/,  type  system 


supported  by  the  resource  r  available  before  the  alternative  resource  r'  is  selected.  This 
ensures  the  correctness  of  the  propagation  of  p,  outside  the  scope  of  the  user  (•). 

The  rules  for  application  and  callcc  set  the  correspondence  between  the  available  re¬ 
source  and  the  resource  required  by  the  invoked  function.  In  addition,  (Exp-callcc)  and 
(Exp-throw)  specify  that  the  continuation  type  is  annotated  with  the  same  resource, 
which  is  needed  by  the  context  captured  in  the  continuation  and  therefore  must  be 
matched  when  it  is  reactivated.  The  effect  of  evaluating  a  callcc  includes  CC,  while 
the  effect  of  a  throw  is  that  of  the  rest  of  the  computation,  which  we  estimate  as  the 
maximal  possible  with  the  current  resource. 

By  induction  on  the  structure  of  a  typing  derivation  it  follows  that  if  a  term  has  a  type 
in  a  given  environment,  it  has  exactly  one  type,  and  the  presence  of  type  annotations 
allows  its  effective  computation,  i.e.  there  exists  a  function  EffTypeOf  such  that 

EffTypeOf  ( r ,  A,  r ,  e )  =  (p,  a)  if  and  only  if  r;  /A;  r  He:  -a. 

We  will  also  use  the  function  TypeOf  with  the  same  arguments,  returning  the  type  a 
only. 

4.2  Dynamic  Semantics 

The  operational  semantics  of  RL  (Figure  4)  is  defined  by  means  of  a  variant  of  the 
tail-call-safe  CaEK  machine  (Flanagan  el  al.  [4]).  The  machine  configuration  is  a  tuple 
(e,  E,  0,  p)  where  e  is  the  current  term  to  be  evaluated,  E  is  the  environment  mapping 
variables  to  machine  values,  O  is  a  heap  of  objects  (closures),  and  p  is  a  tuple  of  machine 
resources.  Depending  on  the  allocation  strategy  used,  p  is  either  a  continuation  stack  S, 
recording  (as  in  the  original  CaEK  machine)  the  context  of  the  evaluation  as  a  sequence 
of  activation  records,  or  a  pair  of  a  current  continuation  k  and  a  continuation  heap  K. 
In  the  latter  form  k  is  a  continuation  handle  and  K  is  a  mapping  from  ContHandles  to 
activation  records  which  offers  non-sequential  access.  In  neither  case  does  a  function 
application  (a  pp)  perform  additional  allocations  of  activation  records,  so  both  strategies 
are  tail-call  safe. 

Machine  values  are  either  small  constants  or  pointers  into  other  structures  where 
larger  objects  are  allocated.  All  closures  are  allocated  on  the  heap  (the  function  7  at  the 
bottom  of  the  figure  shows  the  details). 

The  activation  records  created  when  evaluating  a  letr -expression  may  be  allocated 
either  on  the  continuation  heap  K  (transition  rule  (letH ))  or  on  the  continuation  stack  S 
(rule  ( lets )).  An  activation  record  represents  a  continuation,  and  in  our  small  language 
there  are  only  three  possibilities:  the  computation  either  halts  or  continues  by  binding  a 
variable  to  a  computed  value  or  by  restoring  a  resource.  Rules  (valH)  and  (vals)  perform 
the  binding,  depending  on  the  allocation  mode. 

The  evaluation  of  user  (e)  selects  the  activation  record  allocation  strategy  for  e,  e.g. 
uses  (e)  selects  stack-based  allocation  for  e  (transition  rule  (uses)).  When  the  current 
allocation  resource  is  already  r  we  define  user  (•)  as  a  no-op;  if  a  change  of  resource 
is  performed,  an  activation  record  is  pushed  on  (the  top  of)  the  new  allocation  resource. 
Correspondingly,  heap-based  allocation  is  restored  by  transition  rule  (resume1"1)  after 
the  evaluation  of  e. 


Semantic  Domains 

MachineVal  3  w  ::=  Const  c  |  Ptr  h  |  Cont  k 
E  €  Var  — >  MachineVal 
h  €  HeapLocs 

Object  3  o  ::=  Closure  {x,  e,  E)  |  TyAbs  (t,r,  v) 

O  €  HeapLocs  — >  Object 
k  €  ContHandles 

ActRcd  3  a  ::=  Bind  {x,e,E,k)  |  Resume  5  |  Halt 
K  €  ContHandles  — »  ActRcd 
S  ::=  Bind  (x,e,E,S)  |  Resume  {k,  K)  |  Halt 


machine  values 
environment 
heap  locations 
closures  (objects) 
object  heap 
continuation  handles 
activation  records 
activation  record  heap 
activation  record  stack 


Transition  Rules 

(app)  (Oxi  x2,  E,  O,  p)  i-A-i  <e',  E'[x'  ha  E(x2)\,  O,  p) 

where  E(xi)  =  Ptr  h,  0(h)  =  Closure  { x',e',E ') 

for  Heap-Allocated  Activation  Records 

(letH)  {letH  x  =  ei  in  e2,  E,  H,  { k ,  K ))  hAi 

(ei,  E,  H,  {k1 ,  K[k'  i-A  Bind  (x,  e2,  E\FV^e2)-x,  *>])> 

(valH)  {{ v)H ,  E,  H,  (k,  K))  ^  {e1,  E'[x'  ^  to],  O',  {k1 ,  K)) 

where  K(k)  =  Bind  {x1 ,  e' ,  E' ,  k'),  { w ,  O')  =  7  ( v ,  E,  O ) 

(callcc)  {callcca:,  E ,  H,  { k ,  K ))  i->i  (e' ,  E'[x'  i-t  Cont  k],  O ,  { k ,  K )) 

where  E(x)  =  Ptr  h ,  0(h)  =  Closure  {x',e',E') 

(throw)  (throwfcr]  xi  x2 ,  E ,  H ,  ( k ,  K ))  (e1 ,  E'[x'  >->■  E(x 2)],  O,  {k1 ,  K )) 

where  E(x  1)  =  Cont  ki,  K(ki)  =  Bind  (x1 ,  e' ,  E' ,  k' ) 

(uses)  (uses  (e),  E,  H ,  (k,  K))  t-Ai  (e,  E,  H,  (Resume  (k,K))) 

(resumes)  {{v)H,  E,  H ,  ( k ,  K))  i-ti  {{ v)s ,  E,  H ,  ( S )) 

where  K(k)  =  Resume  S 

for  Stack-Allocated  Activation  Records 


(lets)  (lets  x  =  ei  in  e2,  E,  H,  {S))  1-A1  (ei,  E,  H,  (Bind  (x,  e2,  E\FV(E2)_x,  S))) 

(vals)  (( v)s ,  E,  H ,  (Bind  {x',e',E',  5)»  ^1  (e\  E'[x'  >->  w],  O' ,  (5)) 

where  ( w ,  H ')  =  7  ( v ,  E,  O) 

(useH)  (useH  (e),  E,  H ,  (5))  (e,  E,  H,  (k,  [k  i-t  Resume  5])) 

(resumeH)  ((v)s,  E,  H ,  (Resume  ( k,K )))  h->i  ((v)h,  E,  H ,  {k,  K )) 


Representation  of  Values 

7  (c,  E,  0)=(Const  c,  O)  7  (Ar  x:a.e,  E,  0)=(Ptr  h ,  0[h  (->■  Closure  {x,  e,  E\FV(ey_x )]) 
7  (x,  E,  0)=(E(x),  O)  'y(At<r.  v,E,  0)=(Ptr  h ,  0[h  ha  TyAbs  {t,r,v}]) 

where  h  Dom  (O) 

7  (x[p\,  E,0)  =  7  ([p/t]v,  E,  O)  if  E(x)  =  Ptr  h1 ,  O(h')  =  TyAbs  ( t,r,v ),  and  p  <  r 

Fig.  4.  Semantics  of  RL 


Another  no-op  is  the  increase  of  effect  sets  {-)M  which  only  serves  type-checking 
purposes. 

4.3  Soundness  of  the  Type  System 

The  type  system  maintains  the  property  that  the  effects  of  well-typed  programs  are 
possible  with  their  available  resources,  formalized  in  the  following  statement,  proved 
by  induction  on  the  typing  derivation. 

Lemma  1.  Ifr;  A\  T  He:  —a  is  a  valid  typing  judgment,  then  A  H  p  <  r. 

Semantically  this  behavior  of  well-typed  programs  is  expressed  as  soundness  with 
respect  to  resource  use,  extending  the  standard  soundness  for  safety  of  the  type  system, 
in  the  following  theorem. 

Theorem  1.  Ifr\  0;  0  He:  —a,  then  the  configuration  (e,  0,  0,  Halt  r)  either  diverges 
or  evaluates  to  the  configuration  ((v)r ,  E,  O,  (Halt  r))  (for  some  v,  E  and  O),  where 
Halt  s  =  (Halt)  ,  and  Halt  H  =  ( k ,  K)  for  some  k  and  K  such  that  K(k )  =  Halt . 

This  result  is  a  corollary  of  the  standard  properties  of  progress  and  subject  reduction 
of  the  system,  the  proofs  of  which  we  sketch  below.  To  simplify  the  proofs,  we  introduce 
a  type-annotated  version  of  the  semantics,  which  maintains  type  information  embedded 
in  the  runtime  representation.  Thus  the  representation  of  an  abstraction  in  the  type- 
annotated  version  is 

7  ( Xr  x:o.  e,  E,  0)  =  (Ptr  h,  0[h  •— >  Closure'  ( r ,  x,  o,  e,  E\FV(e)-x)]) 

In  addition,  the  runtime  environment  E  is  extended  to  keep  the  type  of  each  value  in  its 
codomain;  the  value  component  of  E  is  denoted  by  VE  and  the  type  component  by  rE. 
The  following  definitions  are  helpful  in  defining  typability  of  configurations. 

Definition  1.  The  bottom  bot(p)  of  an  allocation  resource  p  is  defined  as  follows: 

1.  if  p  =  (S),  then  bot(p)  =  bot(S'),  if  S  =  Bind  (x1 ,  e',  E' ,  S'),  and  bot(p)  =  S 
otherwise; 

2.  if  p  =  (k,K),  then  bot(p)  =  bot((k' ,K)),  if  K(k)  =  Bind  (x1 ,  e' ,  E' ,  k'),  and 
bot(p)  =  K(k )  otherwise. 

Definition  2.  The  outermost  continuation  heap  outerCont(p)  reachable  from  alloca¬ 
tion  resource  p  is 

1.  K  if  p  =  (k,K)  and  bot(p)  =  Halt; 

2.  outerCont((S ))  if  p  =  (k,K)  and  bot(p)  =  Resume  S; 

3.  0,  if  p  =  (5)  and  bot(p)  =  Halt 

4.  outerCont((k,  K))  if  p  =  ( S )  and  bot(p)  =  Resume  ( k,K ). 

Definition  3.  A  configuration  closed  in  type  environment  r  is  typable  under  resource 
r  with  a  result  type  a  and  an  effect  p,  written  r;  T  H  (e,  E,  0,  p)  :  —a,  if  for  some 
o',  p! 


1.  Dom  (E)  n  Dom  ( E )  =  0;  and 

2.  r;  0;  E,  TE  he:  —a';  and 

3.  r  h  ( p,E ,  0)  €  a'  <j;  and 

h 

4.  for  each  x  €  Dom  (E), 

(a)  if  vE(x)  =  Const  c,  f/zen  TE(x)  =  0(c); 

(&)  if  vE(x )  =  Ptr  h  and  0(h)  =  Closure'  (ri,  a?i ,  <Ji,  ei,  Ei),  f/zezz 

0;TEi  h  Ari  £i  :<7i.  ei  :  TE(x),  and  similarly  for  type  abstractions; 

(c)  if  vE(x)  =  Cont  k,  then  TE(x)  =  a i  7,1  cont  and 

r  h  ( k ,  outer Cont(p)),  E,0  £  <ti  A-  <r( 

mi 

and  p  =  piM  p[,  for  some  a(  and  p[, 
and  r  h  (p,  E,0)  G  a1  ^  a  if 

M 

1.  r  =  S  and  p  =  (Halt)  (i.e.  azz  empty  stack)  and  a  =  a'  and  p  =  0;  or 

2.  r  =  S  and p  =  (Bind  (xi,ei,Ei,Si))  and  S;  E,  X\  :  o'  h  {e±,  E\,  0 ,  5i)  :  -<j; 

or 

3.  r  =  S  and  p  =  (Resume  (fe',  iC'))  azzr/  E  ((fc',  K'),E,  0)  £  a1  a, 

M 

and  similarly  for  r  =  H. 

Note  that  the  environment  may  contain  reachable  variables  bound  to  continuations 
even  when  the  current  allocation  resource  is  a  stack.  Type  correctness  of  these  continua¬ 
tions  cannot  be  verified  with  the  stack  resource,  instead  we  have  to  find  the  correspond¬ 
ing  continuation  heap.  However  in  this  case  the  type  system  guarantees  that  the  only 
continuation  heap  to  which  there  are  references  in  the  environment  is  the  outermost 
continuation  heap,  if  such  exists.  The  reason  is  that  although  it  is  possible  to  switch 
to  heap  allocation  after  executing  in  stack  allocation  mode,  there  are  no  invocations  of 
callcc  allowed  since  they  would  introduce  the  CC  effect,  which  is  not  possible  under 
the  stack  resource  (cf.  typing  rule  (Exp-use)  in  Figure  3). 

We  can  now  formulate  the  progress  and  subject  reduction  properties. 

Lemma  2  (Progress).  If  r;  0  H  (e,  E,  0,  p)  :  -a  where  r  corresponds  to  p  (i.e. 
r  =  S  if  p  =  ( S ),  r  =  H  if  p  =  (k,  K)),  and  p  Halt  r ,  then  there  exists  C  such  that 
(e,  E,  0,  p)  t->i  C. 

Lemma  3  (Subject  reduction).  If  C  =  (e,  E,  0,  p)  and  r;  0  Fe  C  :  —a  where  r 
corresponds  to  p,  and  C  t->i  C'  =  (e',  E',  O' ,  p'),  then  r';  0  H  C'  :  —ro  where 
r’  corresponds  to  p',  p  =  p'  V  p[,  and  the  rule  for  this  transition  is  (callcc)  only  if 
p  =  CC  V  p" ,  for  some  p[  and  p" . 

In  brief,  in  the  case  when  e  f  (v)r ,  the  proofs  proceed  by  examining  the  structure 
of  the  typing  derivation  for  r;  0;  E,  TE  h  e  :  —rcr1',  together  with  condition  4  of  Defi- 
nition  3  this  yields  that  the  values  in  the  environment  and  on  the  heaps  have  the  correct 
shape  for  the  appropriate  transition  rule.  In  the  case  when  e  has  the  form  (v)r  the  proofs 
inspect  the  structure  of  the  derivation  ofE  F  (p,  E,  O)  G  o'  a,  which  parallels  the 
decision  tree  for  the  transition  rules  (val)  and  (resume)  and  the  halting  state. 


4.4  Resource  Transformations 


Effect  inference  and  type  correctness  with  respect  to  resource  use  allow  the  compiler 
to  modify  the  continuation  allocation  strategy  of  a  program  fragment  and  preserve  its 
meaning.  The  following  definitions  adapt  the  standard  notions  of  ordering  and  observa¬ 
tional  equivalence  of  open  terms  to  the  resource-based  system. 

Definition  4.  A  context  C  is  a  term  with  a  hole  •;  the  result  of  placing  a  term  e  in  the 
hole  of  C  is  denoted  by  C[e]  and  may  result  in  capturing  effect  and  lambda  variables 
free  in  e.  The  hole  of  a  context  C  is  of  type  (r,  A,  T)  —a  ifC[e ]  is  typeable  whenever 

r;  A;T  he:  -a. 

Definition  5.  S;A;T  h  e  C  e'  :  —a  if  for  all  contexts  C  with  hole  of  type  (r,  A,  T)  =f> 
-a,  all  typed  environments  E  closing  C[e\  and  heaps  O  closing  E,  and  continuation 
stacks  S,  the  configuration  (C[e'\,  E,  0,  ( S ))  converges  if  (C[e],  E,  O,  ( S ))  con¬ 
verges.  Furthermore,  S',  A' T  he  e  «  e!  :  —a  if  S',  A' T  he  e  C  e'  :  —a  and 
S;  A;  r  h  e'  C  e  :  —a. 

One  possible  optimization  is  the  conversion  of  heap-allocating  code  to  stack-based 
strategy  provided  the  code  does  not  invoke  callcc  or  throw,  as  per  the  following  theo¬ 
rem. 

Theorem  2.  IfW\  A\ r  he:  ^a,  then  S \A-,r  h  useH  (e)  «  StkCont a  (e;  r)  : 
where  StkCont  is  the  transformation  defined  as  follows. 

StkCont  a  r)  =  { v)s 

StkCont  a  ((e)^;  E)  =  (StkCont  a  (e;  r))^ 

StkCont  a  (useH  (e);  r)  =  StkCont  a  (e;  r) 

StkCont  a  (uses  (e);  r)  =  e 

StkCont  a  (Q  x\  X2',  r )  =  lets  x[  =  (As  x'2  -.r(x  2).  useH  (0  x\  x'2))s 

in  0  x[  X2 

StkCont  a  (letH  x  =  e\  in  e2\  r)  =  lets  x  =  StkCont  a  (ei ;  r ) 

in  StkCont  a  (e 2 ;  rx,  x:  TypeOf  (H,  A,  r,  e2)) 


5  Translation  from  HL  to  RL 

Programs  in  language  C  €  {HL,  SL}  are  translated  into  RL  by  an  algorithm  shown  in 
Figure  5.  The  algorithm  infers  the  effect  and  resource  annotations  of  a  term  using  fairly 
standard  techniques.  It  is  presented  in  the  form  of  an  inference  system  for  judgments  of 
the  form  A ;  r  p£  eHL  =>  A1  b  e  :  -a,  where  eHL,  A,  and  F  are  inputs  corresponding 
respectively  to  the  C  term  to  translate  (also  overloaded  to  HL  top-level  programs)  and 
the  inherited  effect  and  type  environments,  initially  empty.  The  outputs  of  the  translation 
are  e.  A1,  p.  and  a ,  which  stand  for  the  translated  term,  the  inferred  effect  environment, 
and  the  effect  and  type  of  e  in  environments  A'  and  T ;  thus  the  output  of  the  algorithm 
satisfies  H;  A1;  The:  —a.  The  function  R.  maps  a  language  name  to  the  resources 
available  to  a  program  in  this  language:  7 Z(HL)  =  H  and  1Z(SL)  =  S. 


(Translate-external) 

a'  =  CloseAll  (Maxs (Annotate5 (r,  Dom(A ))),  S) 

a"  =  CloseAll  (Annotate**  (t,  Dom  (A)),  S)  A-,Tx,x  :  <7"  I bHip  =>  A'  be':  -cr 

A;  r  \-HL  external(SL)  x  :  r  in  p 

=>  A'  b  Ah  x  :a' .  letH  x  =  Wrap^  (•,  x,  a')  in  e'  :  (a1  A  cr) 

where 

Annotate r  (/3,  V)  =  (3 

Annotater  (r  cont,  F)  =  ( Annotate r  (r,  F))  rcont 
Annotate r  (r  — »■  r',  7)  =  <t4  cr'  where  t  e  EffVar  —  V, 

1  <7  =  Annotater  (r,  V  U  {t}) , 

a'  =  Annotater  (r,  F  U  {t}  U/er(a)) 

Wrap;  (C,  x,Vt<r".a)  =  At<r".  Wraprr  (C'flet’’  x' =  (x[t])r  in  •},  x' ,  a) 

Wraprr  ( C ,  x,  <7i  4ff2)  =  Ar  xi'-a'i-  Ietr  x[  =  ( Wraprri  (•,  *1,  ai))r 

in  Wraprr  (C[letr  X2  =  8  x  x\  in  •],  x2 ,  <72) 
where  ai  =  ConvertTyperr  (ai) 

Wrap;'  (C,  x,  P)  =  C[(x)r'] 

(Translate-app) 

zi;  r  \~c  ei  =>  Ai  b  ei  :  —  <7i  Zii ;  I1  he  e2  =►  zi2  1“  e'2  :  —  a  2  zi' ;  5  b  ai  ~  (c72  A  a) 
t  ^  fev(ai)  U/er(<72)  U  Dom  (zi2)  xi  ^  FF(e'2) 


Zi2  II  zi  ;  D  he  ei  e2  =>  zi  b  let  xi  =  ei  in  let  X2  =  e2  in  ®  xi  X2  : - Sa 

Hi  V H2  V St 

where 

0.  ra  /I  |_  z^i;5i  b  o-i  ~  gj  zj2;S2  b  5ig2  ~  Sia'2  S  =  mgu(S2p,  S2p) 

’L  '  J  Zii  n  A2;  S  b  ai  4  a2  ~  ai  4  a'2 

n  m' 

A;  S  b  ai  ~  <72  zi;  5  b  a  ~  a'  Z\'  =  MinEnv(St  <  r ) 

Z\;  5  b  ai  'cont  ~  <72  'cont  zi  n  zi';5\{<}  b  Vt<r.a  ~  a' 

MinEnv  (t  <r)  =  t  <r  MinEnv  (pi  V  p2  <  r)  =  MinEnv  (pi  <  r)nMin£tw  (/12  < 
MinEnv  (0  <  r)  =  0  MinEnv  (CC  <  H)  =  0 


(Translate-let) 

zi;  r  bcei  =>  zli  b  e'l  :  —  (7i 

(cr(,  Z\2)  =  Close(a  1,  zii,r)  A2',rx,x  :  cr(  he  e2  =>  zi'  b  e'2  :  —  a2 


zi;  J1  he  let  ®  =  ei  in  e2  =>  Zi  b  let  x  =  ei  in  e2  :  - <72 

Ml  V  1*2 

(Translate-abs) 

cr  =  Annotate*^  (r,  Dom  (zi))  A;Tx,x  :  a  \~c  e  =>  A1  be'  :  -cr' 

_ £f _ 

Zi;  D  he  Ax  :  r.  e  =>•  zi'  b  (AH  x:a.  e')H  :  -(cr  -4  (7') 

0  M 

(Translate-callcc) 

zi;D  h,Le  =>  zi'  b  e'  :  -(a  Hcont  -4  a) 
_  m _ _ 

zi;  D  h il  callcc  e  =»  zi'  b  letH  x  =  e'  in  callcc  x  :  -  a 

VCC 


Fig.  5.  Typed  translation  from  HL  to  RL 


Several  auxiliary  functions  are  shown  in  the  figure,  and  the  definitions  of  several 
simpler  functions  are  as  follows.  The  lub  of  two  resources  is  defined  by  r  U  r  =  r  and 

5  U  H  =  H.  The  function  n  for  merging  two  effect  environments  is  defined  as  (A\_  n 

A2)(t)  =  Ai(t)\JA2(t)  if t  €  Dom  (/li) n Dom  (A2),  and  {Ai  n  A2)(t)  =  Ai(t)  on 
the  rest  of  Dom  (zAi)  U  Dom  (A2).  The  free  effect  variables  of  a  type  a  are  denoted  by 
fev(cr);  the  function  Close(a,  A,  T)  returns  the  pair  (Vfj  <  A(ti).a,  where 

{/*}  =  fev(a)  —  fev(r),  and  similarly  we  have  CloseAll  ( a,r )  =  Vfj  <  r.a  where 
{*i}  =fev(a). 

Separately  compiled  external  functions  are  treated  as  parameters  of  the  compiled 
HL  fragment  and  are  wrapped  to  convert  the  HL  resources  (continuation  heap)  to  SL 
resources  (continuation  stack).  The  wrapping  is  performed  by  an  auxiliary  function 
invoked  as  Wraprr  (C,  x,  a),  which  produces  a  term  coercing  x  from  type  o  to  type 
ConvertTyperr  (a)  with  resource  annotations  r'  in  place  of  r,  and  places  it  in  context 
C.  When  compiling  separately,  the  effects  of  an  external  function  are  approximated 
conservatively  by  applying  Max'  to  the  effect-annotated  declared  type  of  the  function; 
by  definition  Maxr(a)  is  <ji - - - >  Maxr  (a2)  when  a  =  <ti  A <72,  and  a  otherwise. 

MaxEff(r)  !-'■ 

This  allows  the  view  of  external  functions  as  effect-polymorphic  without  restricting 
their  actual  implementations. 

6  Related  Work  and  Conclusions 

The  work  presented  in  this  paper  is  mainly  inspired  by  recent  research  on  effect  infer¬ 
ence  [6,  10,  11,23,  24],  efficient  implementation  of  first-class  continuations  [2,  8,  22,  1], 
monads  and  modular  interpreters  [30,  12,  29,  13],  typed  intermediate  languages  [7,  26, 
20,  17,  16,  3],  and  foreign  function  call  interface  [9,  18].  In  the  following,  we  briefly 
explain  the  relationship  of  these  work  with  our  resource -based  approach. 

-  Effect  systems.  The  idea  of  using  effect-based  type  systems  to  support  language 
interoperation  was  first  proposed  by  Gifford  and  Lucassen  [5,  6],  Along  this  direc¬ 
tion,  many  researchers  have  worked  on  various  kinds  of  effect  systems  and  effect 
inference  algorithms  [10,  11,  23,  24,  28].  The  main  novelty  of  our  effect  system  is 
that  we  imposed  a  “resource -based”  upper-bound  to  the  effect  variables.  Effect  vari¬ 
ables  in  all  previous  effect  systems  are  always  universally  quantified  without  any 
upper  bounds,  so  they  can  be  instantiated  into  any  effect  expressions.  Our  system 
limits  the  quantification  over  a  finite  set  of  resources — this  allows  us  to  take  advan¬ 
tage  of  the  effect-resource  relationship  to  support  advanced  compilation  strategies. 

-  Efficient  call/cc.  Many  people  have  worked  on  designing  various  strategies  to  sup¬ 
port  efficient  implementation  of  first-class  continuations  [2,  8,  22,  1].  To  support 
a  reasonably  efficient  call/cc,  compilers  today  mostly  use  “stack  chunks”  (a  linked 
list  of  smaller  stacks)  [2,  8]  or  they  simply  heap  allocate  all  activation  records  [22]. 
Both  of  these  representations  are  incompatible  with  those  used  by  traditional  lan¬ 
guages  such  as  C  and  C++  where  activation  records  are  allocated  on  a  sequential 
stack.  First-class  continuations  thus  always  impose  restrictions  and  interoperabil¬ 
ity  challenges  to  the  underlying  compiler.  In  fact,  many  existing  compilers  choose 
not  to  support  call/cc,  simply  because  call/cc  is  not  compatible  with  standard  C 


calling  conventions.  The  techniques  presented  in  this  paper  provide  opportunities 
to  support  both  efficient  call/cc  and  interoperability  with  code  that  use  sequential 
stacks. 

-  Threads.  Implementing  threads  does  not  necessarily  require  first-class  continua¬ 
tions  but  only  an  equivalent  of  one-shot  continuations  [1].  A  finer  distinction  be¬ 
tween  these  classes  of  continuations  is  useful,  however  the  issues  of  incorporating 
linearity  in  the  type  system  to  ensure  safety  in  the  presence  of  one-shot  continua¬ 
tions  are  beyond  the  scope  of  this  paper. 

-  Monads  and  modular  interpreters.  The  idea  of  using  resources  and  effects  to 
characterize  the  run-time  configuration  of  a  function  is  inspired  by  recent  work  on 
monad-based  interactions  and  modular  interpreters  [30,  12,  29,  13].  Unlike  in  the 
monadic  approach,  our  system  provides  a  way  of  switching  the  runtime  context 
“horizontally”  from  one  to  another  via  the  use'  (e)  construct. 

-  Typed  intermediate  languages.  Typed  intermediate  languages  have  received  much 
attention  lately,  especially  in  the  HOT  (i.e.,  higher-order  and  typed)  language  com¬ 
munity.  However,  recent  work  [7,  14,  21,  17,  3,  16,  15]  has  mostly  focused  on 
the  theoretical  foundations  and  general  language  design  issues.  The  type  system  in 
this  paper  focused  on  the  problem  of  compiling  multiple  source  languages  into  a 
common  typed  intermediate  format.  We  plan  to  incorporate  the  resource  and  effect 
annotations  into  our  FLINT  intermediate  language  [21]. 

-  Foreign  function  call  interface.  The  interoperability  problem  addressed  in  this 
paper  has  much  in  common  with  frameworks  for  multi-lingual  programming,  such 
as  ILU,  CORBA  [27],  and  Microsoft’s  COM  [19],  It  also  relates  to  the  foreign 
function  call  interfaces  in  most  existing  compilers  [9,  18].  Although  these  work  do 
address  many  of  the  low-level  problems,  such  as  converting  data  representations  be¬ 
tween  languages  or  passing  information  to  remote  processes,  their  implementations 
do  not  provide  any  safety  guarantees  (or  if  they  do,  they  would  require  external  pro¬ 
grams  run  in  a  separate  address  space).  The  work  presented  in  this  paper  focuses  on 
interfacing  programs  running  in  the  single  address  space  with  much  higher  perfor¬ 
mance  requirements.  We  emphasize  building  a  safe,  efficient,  and  robust  interface 
across  multiple  HOT  languages. 

We  believe  what  we  have  presented  in  this  paper  is  a  good  first-step  towards  a  fully 
formal  investigation  on  the  topic  of  safe  fine-grain  language  interoperations.  We  have 
concentrated  on  the  issues  of  first-class  continuations  in  this  paper,  but  the  framework 
presented  here  should  also  apply  to  handle  other  language  features  such  as  states,  ex¬ 
ceptions,  and  non-termination.  The  effect  system  described  in  this  paper  is  also  very 
general  and  useful  for  static  program  analysis:  because  it  supports  effect  polymorphism, 
effect  information  is  accurately  propagated  through  high-order  functions.  This  is  clearly 
much  more  informative  than  the  single  one-bit  (or  N-bit)  information  seen  in  the  simple 
monad-based  calculus  [16,  25], 

There  are  many  hard  problems  that  must  be  solved  in  order  to  support  a  safe  and 
fine-grained  interoperation  between  ML  and  safe-C,  for  instance,  the  interactions  be¬ 
tween  garbage  collection  and  explicit  memory  allocation,  between  type-safe  and  unsafe 
language  features  etc.  We  plan  to  pursue  these  problems  in  the  future. 
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